With the emergence of 3G mobile telephony, new packet-based communication technologies using IP (Internet Protocol) have been developed to support the usage of multimedia services, while different mobile and fixed user terminals with new functionalities for multimedia communication are emerging on the market. New services are also constantly being developed for terminal users to increase the field of usage and enhance the quality of experience when generally consuming multimedia services.
An IMS (IP Multimedia Subsystem) network can be used to enable multimedia services by initiating and controlling multimedia sessions for user terminals connected to various different access networks. Multimedia sessions are handled by specific session control nodes in the IMS network, referred to as CSCF (Call Session Control Function) nodes including the nodes P-CSCF (Proxy CSCF) and S-CSCF (Serving CSCF). Further, a database node HSS (Home Subscriber Server) stores subscriber and authentication data, and different application servers are used for delivering the multimedia services.
The signalling protocol called “SIP” (Session Initiation Protocol) is commonly used for handling multimedia sessions in IMS networks and other communication services networks. IMS is mentioned in this description for illustrative purposes, without limiting the invention to IMS networks exclusively. A user and his/her communication terminal is often referred to as a “client”, which term will be generally used here.
A particular example of IMS enabled services is “presence” services, involving publication of presence data of a client to make it available to other clients or applications. Presence data basically refers to the status, situation or state of the client, e.g. including the client's current geographical position, connection status, service availability and terminal capabilities, as well as any personal characteristics, preferences and settings. Presence data can be stored in a presence server in the IMS network, based on the publication of such client related information. These publications may be obtained either from the client's terminal or from the access network used by the client, whenever any presence data of the client becomes available or is updated.
A client may also subscribe for selected presence data of one or more other clients, e.g. according to a predefined list of an established or predefined client group. Presence subscriptions are typically also handled by a presence server in the IMS network and may involve various information filters, admission rules and policies. The subscribing client can then receive notifications from the presence server regarding current presence data, subject to any prevailing filters, rules or policies, either automatically or upon request.
In SIP, a message called “PUBLISH” can be used by clients to provide data to the presence server. This message is used basically to initiate new data, “refresh” data (i.e. confirming that earlier initiated data continues to be valid), modify data, and to terminate data no longer valid. Further, a message called “SUBSCRIBE” can be used by clients to subscribe for presence data of other clients, as handled by the presence server, and only authorised clients are entitled to receive such data. Another message called “NOTIFY” can be used by presence servers to present presence data to subscribing clients. Yet another message called “REGISTER” can be used by clients to log on to an IMS network or an access network.
While presence services are mostly based on the publication of client data, a client may generally subscribe for data of any resource using basically the mechanism described above, which may be, apart from another client, any object of interest such as a document, a content service or information service. For example, a notification for group or data management may refer to changes in a document such as a contact list or address book. Further, notifications for content services or information services may refer to a stock exchange, weather forecast, sports results or any other information updates. In general, a resource data notification may refer to any state changes or updates of an observed resource according to a resource data subscription.
In this description, the term “subscribing client” represents a client that subscribes or requests for resource data, and the term “observed resource” represents a resource for which resource data is published to be available for authorised subscribing clients. In the context of presence services, a subscribing client is referred to as the “Watcher” and an observed client is referred to as the “Presentity”. For example, a notification may also refer to a watcher request basically asking the presentity to authorize the watcher to receive certain presence information.
The SUBSCRIBE message above typically contains a time-out parameter that can be set to determine the duration of the subscription, sometimes referred to as TTL (Time To Live). If the time-out parameter in a SUBSCRIBE message is set to zero, a notification with requested presence data is obtained just once and the subscription is promptly terminated thereafter. If the time-out parameter is set to a certain time period>0, the subscribing client will receive notifications according to some predetermined scheme until the subscription period expires.
FIG. 1 illustrates a conventional procedure for providing presence data, involving a subscribing client A, an observed client B and a presence server 100 which stores presence data for client B in a database 102. A first step 1:1a generally illustrates that presence data is published for the observed client B by frequent PUBLISH messages to the presence server 100 according to conventional routines, either sent from client B or from client B's access network (not shown). A next step 1:1b illustrates that database 102 is updated according to the PUBLISH messages of step 1:1a. Steps 1:1a and 1:1b continue throughout in the background, according to prevailing routines.
In a step 1:2, client A sends a SUBSCRIBE message as a subscription request for presence data of client B, in which a time-out parameter for a desired subscription time period is specified. The presence server 100 then retrieves presence data of client B in a step 1:3, and sends it to client A in an initial notification message SIP NOTIFY, as shown in a step 1:4. As indicated by the dashed arrows in step 1:4, client A may receive such notifications on further occasions during the given subscription time, either at regular intervals or whenever the presence data is changed. In order to prolong or “refresh” the subscription, client A automatically sends further SUBSCRIBE messages just before the subscription time expires, and the presence server will then continue to send notifications to client A.
A subscribing client may also subscribe to presence data of several observed clients, which often results in numerous notifications for updated presence data being sent to the subscribing client. An information delivery server called RLS (Resource List Server) can then be used to collect notifications of multiple clients and send a joint notification for all observed clients to the subscribing client, thereby reducing the number of notifications. This joint notification may contain considerable amounts of data.
FIG. 2 illustrates an RLS 200 providing information to a subscribing client A on clients B, C and D which publish data p to their respective presence servers 206B, 206C and 206D. A user list database 208 maintains various user lists on behalf of subscribing clients such as phone books, contact groups, ad hoc groups or the like. The user lists in database 208 may be configured according to a standard referred to as XDMS (XML (Extensible Markup Language) Document Management Server). In a first shown step 2:1, client A sends a subscription request for presence data on clients B,C,D as indicated by a reference to a predefined user list. RLS 200 then fetches the user list from database 208 in a step 2:2 and establishes back-end subscriptions for presence data of clients B,C,D with presence servers 206B-D to obtain the desired data as notifications therefrom in a step 2:3. In a final step 2:4, RLS 200 sends a joint notification to client A, containing desired data on all clients B-D.
As mentioned above, a notification may contain considerable amounts of data and a subscribing client may also receive several notifications quite frequently, e.g. whenever the observed resources change or update their status or situation. These notifications can potentially become quite expensive for the subscribing client when roaming in a visited network, e.g. on vacation in a foreign country, where higher charging rates are applied as compared to when present in the subscribing client's home network. In addition, some information in the notifications may also be quite uninteresting to the receiving subscriber at present.
Network operators typically have a different charging model for roaming subscribers involving rapidly increasing rates for received amounts of data, while a low cost data rate or “flat” rate is normally applied for subscribers present in the home network. Moreover, the subscriber may not be aware of the higher charging rate for incoming notifications when roaming until receiving the next bill, which might understandably cause frustration and dissatisfaction. As a result, the subscriber may choose to discontinue the resource data subscription(s) or even abandon the home network operator altogether. In general, the problems above could ultimately make the services of providing resource data notifications less attractive.
WO 2008/073009 A1 discloses that notifications with client data are withheld when a subscribing client sends a subscription suspend message to a client data server handling the notifications.
U.S. Pat. No. 6,397,058 B1 discloses that the delivery of an incoming call in a radio communications network is controlled based on the location of a roaming mobile subscriber.